Repository navigation
ci(review-debt-guard): 빚의 기준을 «리뷰어의 공이 남은 PR» 로 [base: develop] - #1148
Merged
Merged
Conversation
리뷰 요청은 알림 수단이지 담당 배정이 아니다. 누구에게 걸렸든 팀에서 한 사람이
리뷰하면 그 PR 은 끝난 것이고, 반대로 아무도 응답하지 않은 PR 이 남아 있으면
요청을 받았든 아니든 리뷰를 미룬 것이다.
그래서 판정 대상을 review-requested 검색이 아니라 열린 PR 전체로 바꾼다.
자기 PR 은 자신이 리뷰할 수 없으므로 빼고, draft 는 리뷰받을 상태가 아니므로 뺀다.
실측(로컬 드라이런, close 직전까지):
koongmai 22
Sadturtleman 20
1hyok 2
열린 non-draft PR 48건 중 아무도 응답하지 않은 것이 22건이고, 그중 20건이
1hyok 의 PR 이라 사람마다 빚이 다르게 잡힌다.
Contributor
🚧 리뷰 적체 가드 — 이 PR 을 닫습니다@1hyok 님이 아직 리뷰하지 않았고 다른 누구도 응답하지 않은 PR 이 2건 있습니다.
이 저장소는 아무도 응답하지 않은 PR 이 1건이라도 남아 있으면 새 PR 을 열 수 없습니다 (#1136). 각 PR 에 필요한 리뷰는 한 건입니다 — 팀에서 누구든 먼저 판정을 내면 그 PR 은 모두의 목록에서 빠집니다. 리뷰 요청이 나에게 걸렸는지는 무관합니다. 되살리는 법위 리뷰를 끝낸 뒤 이 PR 을 다시 여세요. 브랜치는 지워지지 않았고 커밋도 그대로입니다. gh pr reopen 1148리뷰보다 이 PR 이 급하면 |
승인 뒤에 작성자가 손보는 것은 작성자 몫이고, 그 변경을 다시 봐 줄 의무는
누구에게도 없다. 리뷰가 다시 필요하면 작성자가 요청을 걸면 된다.
그래서 «마지막 실질 변경 이후» 라는 시점 조건을 걷어낸다. 판정
(APPROVED·CHANGES_REQUESTED)이 한 번이라도 나온 PR 은 빚에서 제외한다.
커밋 시각을 볼 일이 없어져 parents 조회가 통째로 빠지고, PR 당 API 가 2회에서
1회로 준다. 가드 실행도 그만큼 짧아진다.
실측(로컬 드라이런, close 직전까지):
koongmai 4
Sadturtleman 4
1hyok 0 (통과)
열린 non-draft PR 48건 중 판정이 한 번도 없는 것은 #1133 #1134 #1138 #1139
넷뿐이고 모두 1hyok 의 PR 이라, 두 사람의 빚이 각각 4건으로 잡힌다.
승인과 변경요청의 무게가 다르다.
APPROVED 머지 가능한 상태다. 그 뒤 작성자가 손보는 것은 작성자 몫이고
다시 봐 줄 의무는 누구에게도 없다.
CHANGES_REQUESTED 끝난 판정이 아니다. 작성자가 지적을 반영하면 공이 리뷰어에게
돌아온다. 재리뷰가 없으면 그 PR 은 영영 머지되지 못한다.
직전 커밋은 둘을 «판정 1건» 으로 묶어, 변경요청을 받고 반영까지 끝낸 #821 이
빚에서 빠졌다. 그 상태로는 아무도 재리뷰할 의무가 없어 PR 이 갇힌다.
그래서 빚을 두 종류로 나눈다.
1. 아무도 판정을 내지 않은 PR
2. 미해소 변경요청이 있는데 작성자가 이미 반영 커밋을 올린 PR
변경요청 뒤로 새 커밋이 없으면 공은 아직 작성자에게 있으므로 빚이 아니다.
반영 여부는 병합 커밋(parents 2개 이상)을 뺀 실질 커밋으로만 센다.
실측(로컬 드라이런, close 직전까지):
koongmai 11
Sadturtleman 11
1hyok 0 (통과)
#1133 아무도 판정하지 않음
#966 승인됨, 빚 아님
#821 변경요청 반영(4커밋) 뒤 재리뷰 없음
#958 변경요청 미반영, 공은 작성자에게
Contributor
🚧 리뷰 적체 가드 — 이 PR 을 닫습니다@1hyok 님이 아직 리뷰하지 않았고 다른 누구도 응답하지 않은 PR 이 2건 있습니다.
이 저장소는 아무도 응답하지 않은 PR 이 1건이라도 남아 있으면 새 PR 을 열 수 없습니다 (#1136). 각 PR 에 필요한 리뷰는 한 건입니다 — 팀에서 누구든 먼저 판정을 내면 그 PR 은 모두의 목록에서 빠집니다. 리뷰 요청이 나에게 걸렸는지는 무관합니다. 되살리는 법위 리뷰를 끝낸 뒤 이 PR 을 다시 여세요. 브랜치는 지워지지 않았고 커밋도 그대로입니다. gh pr reopen 1148리뷰보다 이 PR 이 급하면 |
This was referenced Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
리뷰 요청은 알림 수단이지 담당 배정이 아니다. 누구에게 걸렸든 팀에서 한 사람이 리뷰하면 그 PR 의 리뷰는 채워진 것이고, 반대로 아무도 응하지 않은 PR 이 남아 있으면 요청을 받았든 아니든 리뷰를 미룬 것이다.
종전 판정의 문제는 두 가지였다.
review-requested:<나>로 조회해서, 나에게 요청이 안 걸린 PR 은 아무도 리뷰하지 않았어도 내 빚이 아니었다.무엇을 바꿨나
① 판정 대상을 열린 PR 전체로 — 요청 목록이 아니라 저장소의 열린 PR 을 훑는다. 자기 PR(자신이 리뷰할 수 없음)과 draft(리뷰받을 상태가 아님)는 제외한다.
② 승인과 변경요청을 구분한다
APPROVEDCHANGES_REQUESTED변경요청을 «판정 1건» 으로 묶어 버리면, 지적을 받고 반영까지 끝낸 PR 을 아무도 다시 볼 의무가 없어져 그 PR 이 갇힌다. 그래서 빚은 두 종류다.
변경요청 뒤로 새 커밋이 없으면 공은 아직 작성자에게 있으므로 빚이 아니다. 반영 여부는 병합 커밋(
parents2개 이상)을 뺀 실질 커밋으로만 센다 — develop 전파는 반영이 아니다.review-request-all은 그대로 둔다. 판정에서는 빠지지만 알림·GitHub UI 필터 역할은 그대로다.실측
로컬에서
gh pr close직전까지 드라이런한 결과다.판정 근거 표본:
빚 11건은 #810 #821 #863 #914 #972 #1094 #1098(반영 후 재리뷰 없음) + #1133 #1134 #1138 #1139(아무도 안 봄)이고 전부
1hyok의 PR 이라, 두 사람에게 각각 11건으로 잡힌다.검증
YAML 파싱과 두 job 의
bash -n통과. 위 수치와 판정 근거는 워크플로의run블록을 그대로 추출해 실행한 것이라 실제 판정과 같은 코드다.시각 변경 없음.